The present invention is related to semiconductor memory devices, and in particular to erasable and programmable nonvolatile memory modules which are connected to a host platform using the USB PC Bus.
Erasable and programmable non-volatile memory modules, hereinafter referred to as flash memory or flash devices, are known in the art for storage of information. Flash devices include electrically erasable and programmable read-only memories (EEPROMs) made of flash-type, floating-gate transistors and are non-volatile memories similar in functionality and performance to EPROM memories, with an additional functionality that allows an in-circuit, programmable, operation to erase pages of the memory. One example of an implementation of such a flash device is given in U.S. Pat. No. 5,799,168, incorporated by reference as if fully set forth herein.
Flash devices have the advantage of being relatively inexpensive and requiring relatively little power as compared to traditional magnetic storage disks. However, in a flash device, it is not practical to rewrite a previously written area of the memory without a preceding page erase of the area. This limitation of flash devices causes them to be incompatible with typical existing operating system programs, since data cannot be written to an area of memory within the flash device in which data has previously. been written, unless the area is first erased. A software management system, such as that disclosed in U.S. Pat. No. 5,404,485, filed on Mar. 5, 1993, which is incorporated as if fully set forth herein, is required to manage these functions of the flash memory device.
Currently, these flash memory devices have a second limitation, which is that they must be either attached statically to the host platform, or attached and detached dynamically using the PCMCIA [Personal Computer Memory Card International Association] interface. Both implementations have drawbacks, including difficulty of use and high cost.
A more useful implementation would follow the USB standard, as described in the USB Specification Version 1.1 which is incorporated as if fully set forth herein. The USB standard offers a smaller form factor and greater ease of use for the end user, while lowering the cost of the implementation. This standard is specified to be an industry-wide standard promoted by companies such as Compaq Computer Corporation, Microsoft, IBM and Intel to serve as an extension to the PC architecture with a focus on Computer Telephony Integration (CTI), the consumer, and productivity applications.
The criteria which were applied to define the architecture for the USB standard include the ease of PC (personal computer) peripheral expansion, low cost, support of transfer rates up to 12 Mb/second and full support for real-time data, voice, audio, and compressed video. This standard also offers protocol flexibility for mixed-mode isochronous data transfers and asynchronous messaging, integration in commodity device technology and provision of a standard interface for rapid integration into any given host product. In addition, the USB standard represents a single model for cabling and attaching connectors, such that all of the details of the electrical functions, including bus terminations, are isolated from the end user. Through the standard, the peripheral devices are self-identifying, and support automatic mapping of functions to a driver. Furthermore, the standard enables all peripheral devices to be dynamically attachable and re-configurable.
A system constructed according to the USB standard is described by three separate, defined areas: USB interconnection, USB devices and the USB host platform. The USB interconnection is the manner in which USB devices are connected to, and communicate with, the host platform. The associated functions and components include the bus topology, which is the connection model between USB devices and the host platform.
The USB physical interconnection has a tiered star topology. A hub is at the center of each star. Each wire segment is a point-to-point connection between the host platform and a hub or function, or a hub connected to another hub or function.
In terms of a capability stack, the USB tasks which are performed at each layer in the system include a data flow model and a schedule. A data flow model is the manner in which data moves in the system over the USB between data producers and data consumers. A schedule determines access to the interconnection, which is shared. Such scheduling enables isochronous data transfers to be supported and eliminates arbitration overhead.
The USB itself is a polled bus. The host controller on the host platform initiates all data transfers. All bus transactions involve the transmission of up to three packets. Each transaction begins when the host controller, on a scheduled basis, sends a USB packet describing the type and direction of transaction, the USB device address, and endpoint number. This packet is referred to as the “token packet.” The USB device, to which the packet is addressed, selects itself by decoding the appropriate address fields. In a given transaction, data is transferred either from the host platform to a device or from a device to the host platform. The direction of data transfer is specified in the token packet. The source of the transaction then sends a data packet or indicates that the source has no data to transfer. The destination, in general, responds with a handshake packet indicating whether the transfer was successful.
The USB data transfer model between a source and destination on the host platform and an endpoint on a device is referred to as a “pipe”. There are two types of pipes: stream and message. Stream data has no USB-defined structure, while message data does. Additionally, pipes have associations of data bandwidth, transfer service type, and endpoint characteristics like directionality and buffer sizes. Most pipes come into existence when a USB device is configured. One message pipe, the default control pipe, always exists once a device is powered, in order to provide access to the configuration, status, and control information for the device.
The transaction schedule for the USB standard permits flow control for some stream pipes. At the hardware level, this prevents situations in which buffers experience underrun or overrun, by using a NAK handshake to throttle the data rate. With the NAK handshake, a transaction is retried when bus time is available. The flow control mechanism permits the construction of flexible schedules which accommodate concurrent servicing of a heterogeneous mix of stream pipes. Thus, multiple stream pipes can be serviced at different intervals with packets of different sizes.
The USB standard, as described, has three main types of packets, including token packets, data packets and handshake packets. An example of each type of packet is shown in background art FIGS. 1-3. Background art FIG. 4 shows an exemplary USB abstract device.
A token packet 10, as shown in background art FIG. 1, features a PID (packet identification) field 12, specifying one of three packet types: IN, OUT, or SETUP. If PID field 12 specifies the IN packet type, the data transaction is defined from a function to the host platform. If PID field 12 specifies the OUT or SETUP packet type, the data transaction is defined from the host platform to a function.
An ADDR field 14 specifies the address, while an ENDP field 16 specifies the endpoint for token packet 10. For OUT and SETUP transactions, in which PID field 12 specifies that token packet 10 is an OUT packet type or a SETUP packet type, ADDR field 14 and ENDP field 16 uniquely identify the endpoint for receiving the subsequent data packet, shown in FIG. 2, which follows after token packet 10. For IN transactions, in which PID field 12 specifies that token packet 10 is an IN packet type, ADDR field 14 and ENDP field 16 uniquely identify which endpoint should transmit a data packet. A CRC5 field 18 contains the checksum, for determining that token packet 10 has been received without corruption. Only host platform can issue token packets 10, such that token packets 10 provide control over transmission of the subsequent data packets.
As shown in background art FIG. 2, a background art USB data packet 20 also features a PID (packet identification) field 22 for identifying the type of data packet. Data packet 20 also features a data field 24 for optionally, containing data, and a CRC field 26 for containing the checksum as previously described.
Background art FIG. 3 shows a background art USB handshake packet 28, which features only a PID (packet identification) field 30. Handshake packets 28 are used to report the status of a data transaction and can return values indicating successful reception of data, command acceptance or rejection, flow control, and halt conditions. Only transaction types which support flow control can return handshake packets 28. Handshake packets 28 are always returned in the handshake phase of a transaction and may be returned, instead of data packets 20, in the data phase of a transaction.
These three different types of packets are exchanged during various phases of the transaction which includes a USB device. A schematic block diagram of the functional blocks in a typical USB device 32 is shown in FIG. 4 for an abstract background art USB device. USB device 32 typically includes a USB electrical interface 34, featuring a cable and a connector, which is a physical interface for receiving and transmitting electrical signals which are compatible with the USB specification as previously described. The signals are then passed to a logical interface 36, which includes one or more buffers, the device address decoder for decoding the address of the source device for the signals, and a SYNC field synchronizer for synchronizing the signals. Information and structures required for management of USB abstract device 32 as a USB device are stored in a USB class control and enumeration engine 38. A function and device engine 40, also termed the “application”; controls and manages the specific functions and properties of USB abstract device 32. In addition, function and device engine 40 also consumes and produces most of the data over the USB bus.
The USB specification does not define the relationship between different entities in USB abstract device 32, however. Rather, the USB specification describes only the requirements for the packets, and for the electrical and physical connection between USB abstract device 32 and the bus. Therefore the connections and relationships shown in background art FIG. 4 are only one example of an implementation which fulfills the requirements of the USB specification. Thus, any specific device for fulfilling the USB specification must have a specifically defined and described architecture.
Unfortunately, no such architecture exists for a flash memory device containing one or more flash memory modules, which would enable the flash memory device to connect to a bus defined according to the USB specification and thereby to form part of a USB system on a host platform. For example, U.S. Pat. No. 5,799,168 does not teach or suggest such an implementation for the flash device. As mentioned previously, such an architecture would be particularly useful for a number of reasons, including low cost, ease of use and transparency to the end user.
There is thus a need for, and it would be useful to have, an architecture for defining and describing a flash memory device which is compatible with a USB system and which follows the USB specification, such that the flash memory device could sit on a USB-defined bus and communicate with the host platform through this bus.